Release 1.3.20 — domains CLI, Remotion fix, new commands - #11

…ing's dead route

TWO THINGS, ONE WORKFLOW.

1. FIX — leads:meeting POSTed /api/chat/start, which is DEAD. It 404s on every call.
   platform-eval.ts already hit and fixed this exact failure (#146509: "the old harness
   POSTed to the dead raichu.heyiris.io/api/chat/start route → 404 on every test →
   false 0/7") by switching to streamAgentChat. leads:meeting never got the same fix, so
   a command whose entire purpose is turning a transcript into lead intel has been failing
   at the last step — AFTER reading the file and printing "Analyzing transcript with AI…",
   which makes it look supported right up until it produces nothing.
   Its default agent was also hardcoded to #11, which returns "Resource not found".

2. NEW — `iris meetings`. Wispr Flow keeps one directory per meeting under
   ~/Library/Application Support/Wispr Flow/meetings/<uuid>/refined.ndjson. Nothing
   surfaced it, so using a call meant finding the UUID by hand, converting NDJSON, and
   passing a path. Now:

     iris meetings                                  list recent sessions
     iris meetings 8ba439fd --bloq 570              summarise + file it
     iris meetings 8ba439fd --export out.txt        just the transcript
     iris meetings 8ba439fd --bloq 570 --raw        verbatim, no AI

   Sessions resolve by id prefix. --bloq finds or CREATES a "Meetings" list, so every
   client project accumulates its calls in the same place without anyone deciding where
   they go — a standard workflow rather than a convention people have to remember.

DELIBERATE CHOICES:
- Speakers are surfaced as diarised ids, not guessed names. Diarisation splits one person
  across ids routinely; a wrong name silently mis-attributes a commitment, which is worse
  than no name. --speaker 2=Arthur labels them when you know.
- Every export carries a header saying Wispr records SYSTEM audio, so your own mic may be
  absent and one side of the conversation can be missing. Verified on a real 56-minute
  client call where the local speaker was entirely uncaptured — reading that transcript
  without the warning would give a confidently one-sided account.
- Extraction failure is NOT fatal. It falls back to filing the raw transcript, because a
  filed transcript beats a lost meeting.
- The extraction prompt forbids inventing names, numbers, dates or commitments, and asks
  it to flag one-sidedness rather than infer the missing half.

Verified end to end on a real 222-segment, 56:47 client call: listed, extracted, created
the Meetings list on bloq 570 and filed item #179213 with accurate decisions and owners.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017HeisVSNVkwQPv3zvoJJUA

…ed on a 404

`iris integrations list` collapsed every probe failure into "unverified — could
not probe", which tells the reader nothing and cost real debugging hours.

Two worse bugs surfaced while fixing that:

1. The gmail and google-drive probes returned "verified" for ANY response that
   was not 401/403 — including 404 and 500. Both probe endpoints currently 404
   (/api/v1/leads/0/gmail-threads, /api/v1/integrations/exec), so Gmail has been
   rendering a green [verified] while its probe does not resolve at all. The
   health signal on those rows was meaningless.

2. Probe results were keyed by integration TYPE, not id, and the drive probe
   never passed integration_id. All three google-drive accounts (#4, #11, #12)
   therefore shared one result taken from whichever connection the API picks by
   default — two accounts could be dead and every row would show the third's
   status. The comment directly above that code says multi-account visibility is
   the point of the command.

Changes:

- Probes return { state, reason, fix } instead of a bare string, so every row
  states its cause and, where one exists, the command that fixes it.
- New "unknown" state, distinct from failure. A 404 on the PROBE path means we
  cannot determine the integration's health; claiming either verified or
  unverified would be unsupported. Rendered neutral rather than red, because the
  fix belongs to us, not the user.
- Network failures are classified — connection refused / timeout / DNS — rather
  than collapsing into one string.
- Results keyed by integration id; the drive probe passes integration_id so each
  account is genuinely probed.
- The calendar probe distinguishes bridge-not-running, no-bridge-key,
  key-rejected and HTTP-n, each with `iris hive doctor` as the fix.

    before  gmail #3            [verified]
    after   gmail #3            [unknown] — probe endpoint returned 404; status not determined
    before  google-calendar #2  [unverified] — could not probe
    after   google-calendar #2  [unverified] — no bridge key configured → iris hive doctor

Verified by running the command from source, not by reading the diff. Typecheck
clean; the remaining tsc error (session/llm.ts:88 TS2589) is pre-existing and
reproduces with this change stashed.

Refs #180929, #181016

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`iris eval run` reported "Tests passed 7/7". It counted every non-empty reply as
a pass:

    const passed = results.filter((r) => r.status === "completed").length
    // "completed" = summary.trim().length > 0

Four of the seven scenarios asserted NOTHING — introduction, creative,
tool-awareness, summary — so they passed by existing. The two that did have
keyword checks had their results printed and then excluded from the count. The
number could not go down, which made it a liveness probe wearing a score's
clothes.

Two changes.

1. A test with no assertion cannot pass; it can only run. Verdicts are now
   pass | fail | unscored, and the summary reads "3 / 3 scored · 4 unscored
   (ran, asserted nothing)" instead of 7/7. Same agent, same run, honest number.

2. A second suite that tests THIS agent rather than the model underneath it.
   `core` (Eiffel Tower, 17*24, a haiku) passes identically whether the agent's
   tools, YAML registry and integrations work or are entirely broken, because
   none of it is exercised. `agent` asserts:

     tool-use        the agent CALLED a tool — toolsUsed non-empty. The old
                     "what tools do you have?" is a self-report the agent will
                     happily give from its prompt header while every one of them
                     is unreachable.
     grounding       it reached the workspace at all
     no-fabrication  it declines to invent when asked about something that does
                     not exist

Verified against PATTY (anomalyco#420), not asserted: tool-use called
Pathways_get_firm_directory, grounding called SearchKnowledgeBaseTool. And it
fails honestly — agent #11 returned "Resource not found" and scored 0/3 rather
than passing vacuously.

no-fabrication is documented in-code as flaky BY CONSTRUCTION, because it is a
lexical proxy for a semantic property: the same agent on the same prompt hedged
in wording my list matched once and missed twice. The caveat says to read the
reply on a failure rather than conclude fabrication, and not to put it in a
threshold. Better to ship the limitation written down than a check that looks
deterministic and is not.

No MCP change. `iris_run` already executes any CLI command, so the MCP server
stays at seven tools and picks this up for free.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JQ9915AheUUs2qL2D2u62K